[セッションレポート]Coca-Cola: Migrating to AWS #reinvent

この記事は AWS re:Invent 2014、APP315-JT - Coca-Cola: Migrating to AWS - Japanese Trackのレポートです。

スピーカーはCoca-Cola North AmericaのMicheal Connor。

レポート

2013年の4月3日。スーパーボウルXLVII。イベントだけでなく、マーケターとしても貴重な機会だった。 the cowboys,the showgirls,badlandersという3つのチームが戦うというマーケティングをした。

スーパーボウルの視聴者が投票して、結末を決めるというもの。 こういったデジタルな広告を展開するというのは、IT部門にとっても非常にわくわくするものだった。 普段のトラフィックの10倍がくるものと想定してテストした。絶対うまく行くと思った。 ファーストクォーターまでは問題なかった。セカンドクォーターで2倍以上のレスポンス遅延が発生した。 セカンドハーフにはもうサーバに接続できないような状態になった。 サーバを再起動したり追加したりしたが、どんどんビューワーが増え、Webサーバがパンクした。 おそらく10%程度のユーザしか接続できなかっただろう。 私たちは大きく失敗した。皆をがっかりさせてしまった。 どうしたらよかったのだろう。 過剰な投資は無駄だし、少なければパンクする。ちょうどいいところを探すのがIT部門の仕事。 より良いシステムを提供するために、私たちはAWSを選択した。

Business Case

なぜこの決断をしたのか？コカコーラにおいていつも問題になるのはスケールだった。 クリエイティブなプロモーションがたくさんある。 私の好きなプロモーションはこれ。クリスマスシーズンに、古臭いセーターのデザインを作るコンテストがある。

期間限定の中に何十万人という人にリーチしなければいけないプロモーション。 この課題をどうやって解決していくのか。

大事なのは事業としての収益性。時間とコスト。Cloudにするためにはメリットがきちんと見える必要がある。 単純にクラウドの価格を算出したら既存より高くなった。 なぜなのかを考えた。結果、既存をそのままで考えていたから。運用についての考えが足りていなかった。 Cloudにすることで、不要なものをやめることが出来る。使わないものを使わないことでコスト削減になる。 効率化の重要なポイント。自動化。弾力性のある環境。 アーキテクチャの考え直し。既存の効果なソリューションをAWSのサービスに置き換えることでコスト削減ができる。 最終的に20%のコスト削減ができると判断し、経営陣を説得することができた。

オンプレミスで抱えていた問題。 固定のキャパシティ。スケールができない。 コストが高く、継続的なビリングができない。コストに対する効果が目に見えない。 テクニカルな制限。言語やDBが固定化されていて新しいものにチャレンジができなかった。 運用上の問題。データセンターの人は問題が発生してもシステムにアクセスできない。トラブルを解決できない。 トラフィックがバーストした場合、同じデータセンターの他の顧客にも影響を与えてしまう。 メンテナンスの問題。グローバル展開しているとメンテナンスできる時間を世界全体で考える必要がある。 アカウントの問題。devとopsの責任が分界されていた。

Selection Process

なぜAWSを選んだのか。 オートスケールが非常に重要。コストセーブに効果的。 管理コスト。AWSのフルマネージドサービスでコスト削減できる。 判断基準としてガートナーのMagic Quadrantは参考になった。 こういった第三者判断のレポートはとても重要。これを見て決めた。 複数のクラウドベンダを使おうという意見もあったが、シンプルにするために単一クラウドにした。

Architectural Challenges

私たちのビジネスにとって、AWSのアーキテクチャの中で、どれが役立つのか？どう運用に落とし込むのか？ これを私たちが考える必要があった。 私たちが考えた構成はこれ。MindCraftで作った構成図(新しい！) オートスケール、Elasticな構成。自動拡張ができる。Splunkをオペレーションツールとして使っている。

Solution

以前Nikeの事例を聞いて、同じような悩みを考えられていた。本当に新しい学びがあった。 とても大事な経験を共有頂いてNikeに感謝している。今回は私たちが同じように経験を共有したい。 私たちが使っているソリューション。

Pnguin Curling Case Study。非常に反応があったプロモーション。

システムの構成というのは様々な要素があり複雑。自動化をすることにした。 社内の開発チームが必要なリソースを要求し、運用チームがCloudFormationを使って構成する。 CLoudFormationは本当に助かる。毎回必ず同じ構成が10分程度で立ち上がる。 CloudFormationは構成管理の煩雑さを簡単にしてくれた。

なぜオートメートしているか。 チケットミスがない、環境構成にミスがない、一貫性がある。 オートメートすることで本業に注力できる。

BeanStalk。様々なプラットフォームを使うことができる。 これを全部自分たちでやろうとすると数百万ドルかかる。 それを数クリックで環境が作れる。本当にパワフル。大きなコスト削減になる。 Auto Scallingは管理が大変、自分たちでの設計も必要。BeanStalkを使うことで簡単にAutoScallingが使える。 今までの失敗。いつもハードウェアをピークに合わせて用意していた。 しかしピークは一瞬、あとの80%はピークまでいかない。このコストは無駄。 今は AutoScallingでベースラインとなるリソースの台数で用意している。ピークにはスケールする。 アプリケーションのアップロードは？以前は大変時間がかかっていたが、今はgit commitしてeb deployするだけ。 CloudWatchによって自分たちでシステムを管理できる。Opsがシステムの状態をすぐに把握できる。 システムは二つの環境を作っている。Blue-Green Deployment。ダウンタイムなしでデプロイできる。

Securityは？OSSSEC+Splunkで全てのサーバの状態を把握する。Splunkがセキュリティ上の脅威をすぐに発見できる。 Splunkでビジネスインテリジェンスへ。様々な過去ログをビジネスに変えていく。

コストの可視化。何にどのくらいコストがかかっているのかがすぐにわかる。不要なサービスを不要だとすぐに判断できる。

マイグレーション。windupというソフトウェアを活用した。12 factor appを参考に。

Securityは常に問題だった。たくさんの機能があるために、セキュリティ要件をセキュリティチームに確認すること。 今年はいろいろな攻撃があった(poodle,heartbread,e.t.c.) AWSはそこにタッチしない。セキュリティパッチはユーザの責任。

Results

100サイトを9ヶ月でマイグレートした。 コストは40%オフできた。AWSの歴史は値下げの歴史。これは予想していなかった嬉しい事実。 ゼロダウンタイムのデプロイを作れてる。 DevOpsモデルによりチケットの発行を80%削減できた。

自動化によって手作業を減らし、もっと面白いこと、新しいことにチャレンジできた。 AWSと、ご協力いただいたパートナーに感謝したい。

最後に

CloudFormationはどこでもベタ褒めされてますね。北米コカコーラさんのような大きな会社でのAWSの移行事例派とても興味深かったです。